Версионирование схем в KVS

Рано или поздно, приходит момент когда в работающей и отлаженной системе
возникает требование добавить 4-5 полей, или еще хуже изменить семантику и
структуру полей. Вот пришло такое время для нашей Erlang базы данных -- KVS.

Есть несколько подходов в мире энтерпрайза к этой задаче, с которыми мне
приходилось сталкиваться.

Первый из вариантов это построение так называемой вертикальной базы, где вся
метаинформация у нас хранится в двух таблицах: классы/типы/документы и поля.
Такой способ хранения был в Alfresco, в нашей собственной системе
документооборота в ILS, такой способ хранения XML в oracle. Ну и я уверен вы
еще назовете тысячи фреймворков которые позволяют просто линковать поля к
существующим документам. Плюсы такого подхода невероятная гибкость. Минусы
невозможно автоматически отслеживать версии схем.

Второй вариант это алегбраизировать операции над схемой, сделать ее модификацию
транзакционной. Так например работает liquibase и другие аналогичные миграторы.
Это самый сложный подход, но он зато вцелом самый гибкий и автоматически берет
на себя задачу управления версиями схем.

Как же это происходит в KVS? Приблизительно также как бы это происходило в
Paradox или FoxPro. Для новых версий схем мы просто храним новые таблицы.
Каждая таблица делит какой-то общий заголовок, с которым KVS может работать
полиморфно. Точно также в С мы версионируем бинарные структуры данных в
протоколах. Самый простой способ разделения версий класса это шардирование по
ID. Это подразумевает упорядоченную последовательность генератора ID для
каждого класса. Поскольку в KVS это так, то мы можем задать диапазоны версий
при старте системы:

 {kvs, [{dba,store_mnesia},
        {user,[{interval,1,10340,user},
               {interval,10341,100000,user2}]},


Здесь число 10341 говорит о том, что начиная с этого ID произошел апдейт схемы
для таблицы user. Даже если конвертация семантически невозможна между двумя
версиями ничего страшного мы можем просто написать код которые работает
отдельно с двумя версиями.

Подключение новый версий в метаинформацию выглядит также:

metainfo() ->
    #schema{name=kvs,tables=[
        #table{name=user2,container=feed,fields=record_info(fields,user2)},
        #table{name=user,container=feed,fields=record_info(fields,user),...


Теперь у нас стоит задача, как сделать полиморфный траверсал и линкование
цепочек. Это все уложилось в коммит из 10 строк.

https://github.com/synrc/kvs/commit/120d722bff563d330d9cdf8ef2fa2715bf922524

Таким образом теперь KVS поддерживает версионирование схем.
TAGS (EDIT) #schema, #table, erlang, kvs, n2o, synrc